Summary

Follow-up to #59 (merged). Backfills the ingest_mode and auth_type fields onto every existing pipelines/community/transform_ocsf/*/metadata.yaml, so the new schema applies uniformly across the directory rather than only to entries added after #59.

What changed

• 129 metadata.yaml files modified. Each one gains two new lines inserted immediately after the existing ingestion_method: line:

    ingest_mode: "..."
    auth_type: "..."

• No serializer logic, no pipeline JSON, no other metadata changed. The diff is exactly +258 lines / 0 deletions across 129 files (plus one CHANGELOG entry).

How values were derived

For each transform, ingest_mode is determined by combining two signals:

1. Bound parser metadata (parsers/community/<source_name>/metadata.yaml) when authoritative. If the parser declares format: syslog | CEF | RFC5424 | custom syslog | w3c or ingestion_method containing Syslog or HEC, the parser's declaration wins.

2. Vendor and product knowledge for the ~90 entries where the parser metadata is unclear (format: gron with ingestion_method: streaming or unknown, or no parser binding at all). Examples of the patterns applied:

   • Cisco network kit (firewalls, ASA, Meraki, ISE, Umbrella, etc.) → Syslog
   • Microsoft 365 / Entra / Defender management surfaces → API Call with OAuth
   • AWS managed services delivering to S3 (CloudTrail, ELB, Route 53 Resolver, GuardDuty export, VPC flow) → Other - {object store with SQS notifications} with IAM Role
   • Azure Event Hub-delivered streams (signin, defender email) → Other - {Azure Event Hub stream (AMQP/Kafka protocol)} with OAuth
   • SaaS REST APIs (Okta, Snyk, Wiz, Tenable, Mimecast, Netskope, Proofpoint, GitHub, Google Workspace, Cloudflare, etc.) → API Call with the vendor's typical auth (Bearer Token, API Key & Secret, or OAuth)

auth_type reflects the upstream collector's typical auth pattern (N/A for syslog, IAM Role for AWS object stores, OAuth for Microsoft/Google APIs, API Key & Secret / Bearer Token for vendor REST APIs, etc.). Where the vendor supports multiple ingestion modes, the most-common deployment pattern is recorded.

Per-entry confidence is captured in the staging file .reorg-prep/inventory/transform_ocsf_classifications.tsv (untracked) as one of high (103), medium (17), or low (9). The low entries are genuinely generic placeholders (json_generic_logs, sample_test_logs, microservice_tracing_logs, mail_server_logs, etc.) where a more specific value is not derivable; they use Other - {Explain: ...} with the reason inline.

Resulting distributions

ingest_mode:

auth_type:

What is NOT in this PR (intentional)

• palo_alto_networks_firewall/ is intentionally not modified — it is being removed in pipelines: drop F-graded PAN-OS firewall transform; document PAN-OS variants #60 (open). Both PRs apply cleanly regardless of merge order.
• No directory renames or relocations. Migration of transforms into the push/pull/ structure (and any rename for naming consistency) is a separate follow-up PR.
• No serializer logic changes.
• No pipeline JSON changes. The bound source_name (parser binding) is unchanged for every entry.

Test plan

• CI passes (CodeQL, secret scanning, contributor automation)
• git diff --stat shows exactly 129 metadata.yaml files in pipelines/community/transform_ocsf/, each +2 -0, plus one CHANGELOG entry
• No file outside pipelines/community/transform_ocsf/*/metadata.yaml and CHANGELOG.md was modified
• Spot-check 5 representative entries on github.com to confirm YAML validity and the new fields render correctly:
  • paloalto_logs (Syslog / N/A)
  • okta (API Call / API Key & Secret) — orphan-bound entry
  • aws_cloudtrail (Other - object store / IAM Role) — orphan-bound entry
  • microsoft_eventhub_azure_signin_logs (Other - Event Hub / OAuth)
  • cisco_duo (Syslog / N/A) — parser-bound entry
• Existing grade: blocks at the top of each metadata.yaml are unchanged (the automated grader signal is preserved)